该实践方案主要介绍微服务项目使用gitlab自带的GitLab Continuous Integration (CI) & Continuous Delivery (CD)功能，在gitlab提供的runner里面进行打包、测试、发布。
持续集成主要是代码编译和打包的过程，一般最终会集成一个适合业务场景的系统层docker镜像。下面为集成系统层docker镜像Dockerfile的主要内容：
FROM debian:stretch# 准备软件包文件ADD soft/ /data/soft/# 安装基本软件RUN DEBIAN_FRONTEND=noninteractive apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get install -y vim htop wget dnsutils dmidecode ipmitool pciutils perl \rsync screen less sysstat at stress tcpdump lsof curl telnet ntp rsyslog sudo locales logrotate cron supervisor \numactl openssh-server-x509 openssh-client iptables gawk filebeat mongodb3.4.16 graphviz \ && apt-get clean# 安装开发环境RUN DEBIAN_FRONTEND=noninteractive apt-get update \ && apt-get install -y python python-pip gcc g++ build-essential python-dev python-setuptools python-smbus \build-essential libncursesw5-dev libgdbm-dev libc6-dev zlib1g-dev libsqlite3-dev tk-dev libssl-dev openssl \libffi-dev cmake automake python-setuptools libtcmalloc-minimal4 sockstat strace gdb graphviz \ && apt-get clean# 安装python3.7RUN cd /data/soft/ && tar xf /data/soft/Python-3.7.0.tgz && cd Python-3.7.0 && ./configure --enable-optimizations --with-ssl-default-suites=openssl --enable-shared \ && make && make install && cp libpython3.7m.so.1.0 /lib64/ && ldconfig && rm -rf /data/soft# 业务启动脚本COPY entrypoint.sh /sbin/entrypoint.shENTRYPOINT ["/bin/bash", "-x", "/sbin/entrypoint.sh"]那么怎么把docker镜像推送到docker仓库呢？可在.gitlab-ci.yml文件中进行描述，把build好的镜像推送到gitlab内置的registry中。关于gitlab内置的registry部署可参考官网说明
build_push: only:refs: - tagsvariables: - $CI_COMMIT_REF_NAME =~ /^rel_[0-9].*$/ # 规定必须通过打tag且名字为rel_xxx的格式才触发pipeline。 tags: - docker stage: ex_build script: # build docker image - docker login $DOCKER_REGISTRY - echo "$ docker pull $BUILD_IMAGE" - docker pull $BUILD_IMAGE # 防止$BUILD_IMAGE更新后，runner会缓存，故在build之前先pull一次。 - echo "$ docker build -t $image" - docker build --no-cache -t $image . - echo "$ docker tag $image $latest" - docker tag $image $latest # push docker image - echo "$ docker push $image" - docker push $image - echo "$ docker push $latest" - docker push $latest - docker logout $DOCKER_REGISTRY when: manual # 手工确认 allow_failure: false environment:name: buildgitlab-runner中对应job的部分日志截图如下：
持续交付CD持续交付或者持续发布的方式其实有很多种，理论上只要服务方提供了发布接口，你就可以封装在.gitlab-ci.yml文件里使用gitlab-runner调用api进行自动发布。下面主要介绍容器的发布方式。
发布容器时主要调用自建容器服务的发布接口，其中主要的stage内容如下：
deployment_production: only:refs: - tagsvariables: - $CI_COMMIT_REF_NAME =~ /^exrel_[0-9].*$/ tags: - docker stage: ex_deployment_production script: # 更新当前环境下指定渠道 - deploy_service ${CI_ENVIRONMENT_NAME} "$image" #image为持续集成build后push到registry的docker镜像。deploy_service是封装容器发布过程的函数。该函数主要是根据传入的image，请求k8s的kube接口进行微服务发布。 when: manual environment:name: productiongitlab-runner中发布game微服务的job日志截图如下。
发布流程微服务的发布流程主要分2种类型：常规发布和热更发布。常规发布需要重建容器，热更发布无需重建容器。
下面为常规发布场景下整体的发布流程。
热更发布核心思路是把需要热更的内容put到etcd集群，服务端集群自动获取内容进行热更，下面为热更发布场景下整体的发布流程。
四.效果展示常规发布下的pipeline
热更发布下的pipeline
